Secure multiparty loss resistant storage and transfer of cryptographic keys for blockchain based systems in conjunction with a wallet management system

ABSTRACT

A solution for controlling access to a resource such as a digital wallet implemented using a blockchain. Use of the invention during set-up of the wallet can enable subsequent operations to be handled in a secure manner over an insecure channel. An example method comprises splitting a verification element into multiple shares; determining a common secret at multiple nodes in a network; and using the common secret to transmit a share of the verification element between nodes. The shares can be split such that no share is sufficient to determine the verification element and can be stored at separate locations. Upon share unavailability, the share can be retrieved a location accessibility. For safe transmission of the share(s), the common secret is generated at two different nodes independently and used to generate an encryption key for encrypting at least one share of the verification element to be transmitted securely.

This application is a divisional of U.S. application Ser. No. 16/111,022filed Aug. 23, 2018, entitled “SECURE MULTIPARTY LOSS RESISTANT STORAGEAND TRANSFER OF CRYPTOGRAPHIC KEYS FOR BLOCKCHAIN BASED SYSTEMS INCONJUNCTION WITH A WALLET MANAGEMENT SYSTEM,” which is a continuation ofPCT Application No. PCT/IB2017/050829, filed Feb. 14, 2017, entitled“SECURE MULTIPARTY LOSS RESISTANT STORAGE AND TRANSFER OF CRYPTOGRAPHICKEYS FOR BLOCK CHAIN BASED SYSTEMS IN CONJUNCTION WITH A WALLETMANAGEMENT SYSTEM,” which claims priority to United Kingdom ApplicationNo. 1603117.1, filed Feb. 23, 2016, entitled “DETERMINING A COMMONSECRET FOR TWO BLOCKCHAIN NODES FOR THE SECURE EXCHANGE OF INFORMATION,”United Kingdom Application No. 1605026.2, filed Mar. 24, 2016, entitled“SECURE MULTIPARTY LOSS RESISTANT STORAGE AND TRANSFER OF CRYPTOGRAPHICKEYS FOR BLOCKCHAIN BASED SYSTEMS IN CONJUNCTION WITH A WALLETMANAGEMENT SYSTEM,” and United Kingdom Application No. 1619301.3, filedNov. 15, 2016, entitled “DETERMINING A COMMON SECRET FOR TWO BLOCKCHAINNODES FOR THE SECURE EXCHANGE OF INFORMATION.” The previously notedapplications are hereby incorporated by reference in their entirety.

This invention relates generally to computer and data security, and moreparticularly to secure handling of highly sensitive data items such ascryptographic keys. The invention provides an access control mechanism.The invention is particularly suited for, but not limited to, use withdigital (software) wallets. This may include, for example, wallets usedin relation to cryptocurrencies such as Bitcoin. The invention providesan advantageous access control mechanism.

Cryptography involves techniques for secure storage of sensitive data aswell as its communication between two or more nodes in a network. A nodemay include a mobile communication device, a tablet computer, a laptopcomputer, desktop, other forms of computing devices and communicationdevices, a server device in a network, a client device in a network, oneor more nodes in a distributed network, etc. The nodes may be associatedwith, for example, a natural person, a group of people such as employeesof a company, a system such as a banking system, or a distributed,peer-to-peer ledger (i.e. blockchain).

Two or more nodes may be linked by a communications network that isunsecure and vulnerable to eavesdropping or interception by unauthorisedthird parties. Therefore, messages sent between nodes are often sent inencrypted form. Upon receipt, the intended recipient decrypts themessages with corresponding decryption key(s) or other decryptionmethods. Thus the security of such communication may be dependent onpreventing the third party from determining the corresponding decryptionkey.

One known cryptographic method includes using symmetric-key algorithms.The keys are symmetric in the sense that the same symmetric-key is usedfor both encryption of a plain text message and decryption of the ciphertext message. However, the symmetric-key must be transmitted to bothnodes in a secure way to prevent unauthorised access to it. This mayinclude, for example, physically delivering the symmetric-key to the(authorised) nodes so that the symmetric-key is never transmitted overan unsecure communications network. However, physical delivery in notalways a practical option. Therefore, a problem in such cryptographicsystems is the establishment of the symmetric-key (which may be based ona common secret) between the nodes across an unsecure electronic networksuch as the internet. Thus this step of providing a symmetrical key (thecommon secret) is a potentially catastrophic vulnerability. As thesymmetric-key algorithms and protocols are simple and widely used, thereis a need for two nodes to determine a common secret based symmetricalkey securely across an unsecure network.

The use of asymmetric-keys, also known as public-key cryptography,alleviates this issue to some extent. While the private key is keptsecret its corresponding public key may be made publicly available. Itsinterception on a network is not catastrophic. Existing protocolsinclude the Diffie-Hellman Key Exchange and the Three Pass Protocol.

However, storage of the private key gives rise to significant securityconcerns. Consider, for example, a digital wallet such as a Bitcoinwallet. Digital wallets comprise software which enables a user toconnect with other nodes so as to perform transactions with theirelectronic assets e.g. using bitcoin funds to purchase goods andservices. Public-key cryptography is often used to protect the vitalinformation which is needed for such connections and transactions. Theprivate key is stored either by the wallet installed on the user'sdevice (‘client side’) or by a wallet service provider (‘server side’).However, if the private key is stored only at the client side, theprivate key can be lost through theft, loss or damage caused to theuser's hardware e.g. computer, mobile phone etc. Similarly, if the userdies or becomes incapacitated, knowledge of or access to the private keycan be lost and thus the funds associated with the wallet becomeinaccessible. While server-side storage of the private key can overcomethese problems, the user must be prepared to trust the service providerto keep their private key secure. Security breaches at the server sideare a real and significant risk.

Thus, it is desirable to provide a solution which enables the safehandling of a secret. This secret may be a cryptographic key and/orsomething which may provide access to the key. Such an improved solutionhas now been devised. In accordance with the present invention there isprovided an improved solution as defined in the appended claims.

The invention may provide a computer-implemented method. It may enablethe control of access to a resource. It may be called a verification orauthentication method. It may be referred to as a cryptographic keymanagement solution. The resource may be any type of physical orelectronic resource. In one embodiment, the resource is a digital walletor some other resource relating to a form of currency. It may be aBitcoin wallet or other wallet for the management of cryptocurrencyresources. The invention may provide a method of controlling access to adigital wallet (and corresponding system).

The invention may be used during the set-up, registration or creation ofa digital wallet via an unsecure communication channel (such as theinternet), to enable subsequent wallet-related operations such astransactions to be handled, communicated and/or created in a securefashion.

One or more embodiments of the invention may comprise the step ofderiving the cryptographic key from an existing cryptographic key pair.This may comprise the steps of:

-   -   determining a first entity second private key based on at least        a first entity master private key and a generator value;    -   determining a second entity second private key based on at least        a second entity master private key and the generator value;    -   determining a common secret (CS) at the first entity based on        the first entity second private key and the second entity second        public key, and determining the common secret (CS) at the second        entity based on the second entity second private key and first        entity second public key; and    -   wherein:        -   the first entity second public key and the second entity            second public key are respectively based on at least the            first/second entity master key and the generator value.

Additionally or alternatively, the invention may comprise a method ofcontrolling access to a digital wallet, the method comprising the steps:

-   -   determining a first entity second private key based on at least        a first entity master private key and a generator value;    -   determining a second entity second private key based on at least        a second entity master private key and the generator value;    -   determining a common secret (CS) at the first entity based on        the first entity second private key and the second entity second        public key, and determining the common secret (CS) at the second        entity based on the second entity second private key and first        entity second public key; and    -   wherein:        -   the first entity second public key and the second entity            second public key are respectively based on at least the            first/second entity master key and the generator value.

Additionally or alternatively, the method may comprise the steps:

-   -   splitting a verification element into a plurality of shares;    -   determining a common secret at or on two or more nodes in a        network;    -   using the common secret to transmit at least one share of the        verification element from one node in the network to at least        one other node.

The verification element may be a cryptographic key. It may be a privatekey in an asymmetric cryptography pair. Additionally or alternatively,it may be a representation of a cryptographic key, or some item whichmay be used to access, calculate, derive or retrieve a cryptographickey. It may be some secret or value which can be used in a verificationprocess such as, for example, a mnemonic or a seed.

Thus, one aspect of the invention may relate to splitting a secret suchas a private key into (unique) shares. The verification element may besplit into a plurality of shares such that the verification element canbe restored or regenerated from two or more of the shares. Shamir'sSecret Sharing Scheme may be used to split the verification element intoshares.

The shares may be split such that any share on its own is of no value,meaning that it cannot be used to arrive at the (original, un-split)verification element. The split may be performed such that theverification element can only be restored upon combination of apredetermined number of shares. In one embodiment, any two shares may besufficient for restoration of the verification element.

Another aspect of the invention may relate to safe handling or storageof the respective shares. The shares may be sent to, and stored by,different parties. Some or all of these parties may be nodes on thenetwork. In one embodiment, the method may comprise the step of storingat least three shares of the verification element at different locationsrelative to each other.

At least one of the shares may be stored in or on a back-up or“safe-storage” facility. This may be separate, independent and/ordistinct from any other location which stores a share. This provides animportant advantage, because it enables restoration of the verificationelement in the event that one of the other shares becomes unavailable.In such a situation, the share may be retrieved from the safe-storagefacility.

A verification process may be performed prior to restoration of theverification element using the shares. The verification process maycomprise verification of the identity of a pre-determined or designatedindividual, and/or a computing resource.

Another aspect of the invention may relate to the secure distribution ofone or more of the shares. The method may comprise the step of using thecommon secret to generate an encryption key, wherein the encryption keyis used to encrypt at least one share of the verification element or amessage comprising said at least one share.

The common secret may be determined at the at least two nodesindependently of each other. Thus, each node may determine or generatethe secret for themselves, without input from or communication with theother node or another party. This means that the common secret may notrequire transmission over a communications channel. This providesenhanced security because it cannot be intercepted by unauthorisedparties. The common secret may be common to (i.e. shared by) only the atleast two nodes. The common secret may then be used to generate anencryption key, and that encryption key may be used for the safetransmission of the share(s). Other data may also be transmitted usingthe encryption key.

The method may comprise the step of determining, at a first node (C), acommon secret (CS) that is common with the first node (C) and a secondnode (S), wherein the first node (C) is associated with a firstasymmetric cryptography pair having a first node master private key(V_(1C)) and a first node master public key (P_(1C)), and the secondnode (S) is associated with a second asymmetric cryptography pair havinga second node master private key (V is) and a second node master publickey (P_(1S)), wherein the method comprises:

-   -   determining a first node second private key (V_(2C)) based on at        least the first node master private key (V_(1C)) and a Generator        Value (GV);    -   determining a second node second public key (P_(2S)) based on at        least the second node master public key (P_(1S)) and the        Generator Value (GV); and    -   determining the common secret (CS) based on the first node        second private key (V_(2C)) and the second node second public        key (P_(2S)),    -   wherein the second node (S) has the same common secret (S) based        on a first node second public key (P_(2C)) and a second node        second private key (V_(2S)), wherein: the first node second        public key (P_(2C)) is based on at least the first node master        public key (P_(1C)) and the Generator Value (GV); and the second        node second private key (V_(2S)) is based on at least the second        node master private key (V_(1S)) and the Generator Value (GV).

The Generator Value (GV) may be based on a message (M). The method mayfurther comprise: generating a first signed message (SM1) based on themessage (M) and the first node second private key (V_(2C)); and sending,over the communications network, the first signed message (SM1) to thesecond node (S), wherein the first signed message (SM1) can be validatedwith a first node second public key (P_(2C)) to authenticate the firstnode (C).

The method may also comprise: receiving, over the communicationsnetwork, a second signed message (SM2) from the second node (S);validating the second signed message (SM2) with the second node secondpublic key (P2S); and authenticating the second node (S) based on theresult of validating the second signed message (SM2), wherein the secondsigned message (SM2) was generated based on the message (M), or a secondmessage (M2), and the second node second private key (V_(2S)).

The method may further comprise generating a message (M); and sending,over a communications network, the message (M) to the second node (S).Alternatively, the method may comprise receiving the message (M), overthe communications network, from the second node (S). In yet anotheralternative, the method may comprise receiving the message (M), over thecommunications network, from another node. In yet another alternative,the method may comprise receiving the message (M) from a data store,and/or an input interface associated with the first node (C).

The first node master public key (P_(1C)), second node master public key(P_(1S)) may be based on elliptic curve point multiplication ofrespective first node master private key (V_(1C)) and second node masterprivate key (V_(1S)) and a generator (G).

The method may further comprise the steps of: receiving, over thecommunications network, the second node master public key (P_(1S)); andstoring, at a data store associated with the first node (C), the secondnode master public key (P_(1S)).

The method may further comprise the steps of: generating, at a firstnode (C), the first node master private key (V_(1C)) and the first nodemaster public key (P_(1C)); sending, over the communications network,the first node master public key (P_(1C)) to the second node (S) and/orother node; and storing, in a first data store associated with the firstnode (C), the first node master private key (V_(1C)).

The method may also comprise: sending, over the communications network,to the second node, a notice indicative of using a common elliptic curvecryptography (ECC) system with a base point (G) for the method ofdetermining a common secret (CS). The step of generating the first nodemaster private key (V_(1C)) and the first node master public key(P_(1C)) may comprise: generating the first node master private key(V_(1C)) based on a random integer in an allowable range specified inthe common ECC system; and determining the first node master public key(P_(1C)) based on elliptic curve point multiplication of the first nodemaster private key (V_(1C)) and the base point (G) according to thefollowing formula:P _(1C) =V _(1C) ×G

The method may further comprise: determining the Generator Value (GV)based on determining a hash of the message (M), wherein the step ofdetermining a first node second private key (V_(2C)) is based on ascalar addition of the first node master private key (V_(1C)) and theGenerator Value (GV) according to the following formula:V _(2C) =V _(1C)+GV

The step of determining a second node second public key (P2S) may bebased on the second node master public key (P_(1S)) with elliptic curvepoint addition to the elliptic curve point multiplication of theGenerator Value (GV) and the base point (G) according to the followingformula:P _(2S) =P _(1S)+GV×G.

The Generator Value (GV) may be based on determining a hash of aprevious Generator Value (GV).

The first asymmetric cryptography pair and the second asymmetriccryptography pair may be based on a function of respective previousfirst asymmetric cryptography pair and previous second asymmetriccryptography pair.

In an alternative wording, the invention may provide a method comprisingthe steps: splitting a verification element into a plurality of shares;

-   generating, at a first node, a derived (or second) private    cryptographic key based on a first master asymmetric key pair;-   using the derived private key for the encryption and/or secure    transmission of least one share of the verification element.

The method may also comprise the step of generating, at a second node,the same derived private key, this being generated independently of thefirst node and based on a second master asymmetric key pair.

The derived private key may be part of an asymmetric key pair comprisingthe private key and a public key. The first and/or second nodes may useElliptic Curve Cryptography (ECC) to generate the private key (and itscorresponding public key).

The method may comprise the steps:

-   -   Agreeing on, between the first and second nodes, a standard ECC        system using a base point (G); and/or    -   generating, at the first and/or second node, a public/private        key pair using the agreed standard ECC system and publishing the        public key; this may mean making it publicly available; and/or    -   registering the first node's master public key (P_(MC)) at the        second node or another location; and/or registering the second        node's master public key (P_(MC)) at the first node or another        location; and/or    -   sending a message (M) from the first node to the second node        and/or vice versa, and creating a hash of the message; the        message may be signed using the derived private key; this step        may represent the only transmission required to 1) establish a        shared secret between the nodes and 2) initiate a secured        communication session between them. The first or second node may        use the received message M to generate its own derived        (secondary) public/private key pair. This may allow the node to        calculate the other node's derived public key; and/or    -   receiving the message and independently calculating the hash of        the message M (e.g. SHA-256(M)); and/or    -   calculating a public key (P_(2C)) which is derivable from the        master key (P_(MC)); and/or    -   validating the signature (Sig-V_(2C)) against the calculated        P_(2C)

The derived private key may be deterministically derived from the firstor second node's master public key.

-   The invention may also comprise a computer-implemented system    arranged and configured to implement any embodiment of the method(s)    described above. The system may comprise or utilise a blockchain    network or platform. Additionally or alternatively, it may comprise    a digital wallet provider or management system.

Any feature described above in relation to one aspect or embodiment ofthe invention may also be used in relation to any other aspect orembodiment. For example, and feature described in relation to the methodmay apply to the system and vice versa.

These and other aspects of the present invention will be apparent fromand elucidated with reference to, the embodiment described herein.

An embodiment of the present invention will now be described, by way ofexample only, and with reference to the accompany drawings, in which:

FIG. 1 is a schematic diagram of an example system to determine a commonsecret for a first node and second node, as may be used in accordancewith the present invention for secure transmission of highly sensitiveinformation, such as a share of a private key;

FIG. 2 is a flow chart of computer-implemented methods for determining acommon secret as may be used in accordance with the present inventionfor secure transmission of highly sensitive information, such as a shareof a private key;

FIG. 3 is a flow chart of computer-implemented methods to register thefirst and second nodes;

FIG. 4 is another flow chart of computer-implemented methods fordetermining a common secret as may be used in accordance with thepresent invention for secure transmission of highly sensitiveinformation, such as a share of a private key;

FIG. 5 is a flow chart of computer-implemented methods of securecommunication between the first node and second node.

As explained above, a need exists for enhanced storage and/or exchangeof a secret such as a cryptographic key, or a secret which can be usedto generate a key. The secret may be a seed for a wallet mnemonic, orother security-related item. The invention provides such a solution. Anembodiment is described below for the purposes of illustration, and usesthe context of a digital wallet implemented on a blockchain. However,the invention is not limited to such implementations and could beimplemented in respect of any computer-implemented network or system.

As above, public-key cryptography is often used in relation to digitalwallets. If the end user (which we may refer to as a “client” or simply“user”) is responsible for storing their private key, problems may arisewhen the user or their hardware become unavailable as this renders theprivate key, and thus the wallet's funds, inaccessible. However, storageof the key at the wallet provider's end (which we may refer to as“server side”) requires a degree of trust in that provider and theirsecurity mechanisms. So there is a need to store the private key in sucha way that it cannot be obtained by an unauthorised party, but can alsobe reproduced when necessary. The term “user” may be a human user or acomputer-implemented resource.

One known cryptographic algorithm, known as “Shamir's secret sharingscheme” (4S), teaches splitting the secret up into unique parts orshares which are then distributed to different parties. The shares canbe used to reconstruct the secret thereafter. Each individual share isof no value or use on its own until it is combined with one or moreother shares. The number of shares required to reconstruct the secretcan vary according to the needs of the situation. In some cases, allshares may be required, while in other cases only a sufficient numberare required. This is known as the threshold scheme, where any k of theshares are sufficient to reconstruct the original secret.

In this illustrative embodiment, 4S is used to split a secret such as aprivate key or mnemonic seed into a number of parts. It is then alsoused to regenerate the key or mnemonic seed from a certain number ofparts. The use of mnemonics is known in conjunction with digitalwallets. The mnemonic is a human-friendly code or group of words whichcan be turned into a binary seed for the generation of a wallet or data.

Herein, there following terms may be used.

-   -   “Secret” (S) is a secret (e.g. a number or value) that needs to        be shared securely between parties.    -   “Share” is a piece of the secret. The secret is divided into        pieces and each piece is called a share. It is computed from the        given secret. In order to recover the secret, one must obtain a        certain numbers of shares.    -   “Threshold” (k) is the minimum number of shares that one needs        to regenerate or recover the secret. The secret can be        regenerated only when you have >=k shares.    -   “Prime” (p) is a random prime number.

From a broad perspective, an illustrative embodiment may comprise amethod as follows. In this example, we use a ‘2-of-3’ scheme (i.e. k=2):

-   -   A user registers with a wallet provider to generate and set up a        new wallet associated with that user. In this example, the        wallet is a Bitcoin wallet, which utilises the Blockchain    -   A public-private key pair is generated and associated with the        user's wallet;    -   The private key is split into shares, using 4S    -   One share of the private key is sent via a secure transmission        to the user    -   Another share of the private key is retained by the service        provider and stored on a server    -   Another share is sent via a secure transmission to a remote        location for safe storage. The term ‘remote’ does not imply any        particular geographical distance or location. Instead, it is        used herein to mean that the share is held in, at or on a secure        storage facility or resource which is independent in some sense        from the wallet provider or the user, preferably both.        “Independent” may include physical, logical, financial,        political and/or organisationally independent. For example, the        safe storage may be contracted out to a commercial entity which        provides the safe storage service for a fee; or it may be held        by the user's attorney, or some other elected (and trusted)        party who accepts responsibility for storing the share and        supplying it upon request if needed;    -   The wallet provider can destroy any or all copies of the        complete private key, because it is no longer needed. When the        private key is needed for subsequent authorisation of the user        (e.g. because the user now wishes to make a transaction) the key        can be reconstructed from the user's share, which the user        provides to the wallet provider as and when needed, and the        wallet provider's share.

An advantage of this is that even if the wallet provider's security isbreached, the unauthorised party cannot gain access to the user'sprivate key because it is not stored anywhere on the wallet provider'ssystem and the wallet provider's system alone does not contain enoughshares to allow reconstruction of the private key. This same advantageapplies in situations where the client's security is breached.

Another advantage is that by storing a share at a safe storage location,the private key can be reconstructed by retrieving that share from safestorage and combining it with the wallet provider's share. Thus, if theuser dies or becomes incapacitated, or if the user's hardware (and thusshare) is lost, damaged or stolen, the funds in the wallet can still beaccessed. In such a situation, the user's identity would be verified. Insome cases, the identity of a proven, trusted party such as executor ofan estate or attorney would be verified. This may be achieved, byexample, upon production of evidence such as death certificate,passport, a legal document or other form of identification. Uponverification of authorised identity, the share of the secret would beretrieved from safe storage. Therefore, the safe storage serves as atype of back-up facility which can be used in exceptional orpre-determined circumstances.

Thus, the invention provides an advantageous combination of enhancedsystem/data security plus convenience. It provides a simple, effectiveand secure solution for access control.

It should be noted that in the above example, the private key isgenerated by the wallet service provider and respective parts are sentto the user and safe storage resource. However, this may not be the casein other embodiments. It is also important to note that transmission ofparts between parties, which may be referred to as ‘nodes’, must beperformed in a secure manner because any unauthorised interception ofmultiple shares could enable the interceptor to reconstruct the secret(e.g. mnemonic or key). This secure exchange problem is also addressedby the invention, as described below.

More detailed aspects of the invention are now described for the purposeof illustration. It should be noted that Shamir's Secret Sharing Schemeis a technique which is known in the art, and the skilled person wouldbe aware of, understand and be able to use it. Therefore, the followingis provided for the purpose of completeness only.

Splitting the Secret into Shares

Given a secret S, a number of participants n, a threshold number k, andsome prime number p, we construct a polynomial:y=f(x) of degree k−1 (modulo our prime p)with constant term S.

Next, we choose n unique random integers between 1 and p−1, inclusive,and evaluate the polynomial at those n points. Each of the nparticipants is given a (x, y) pair. This can be achieved by thefollowing steps.

1. Convert into Integer

For the 4S algorithm, the secret needs to be an integer. Hence if thesecret is in some other format (ex. String, hex etc.) it must beconverted into an integer first. If the secret is already an integer,this step can be omitted. For this example, let S=1234.

2. Decide Number of Shares (n) and Threshold (k)

Note that k parts will be required to regenerate the secret. Hence,choose S and k such that k parts can always be obtained while recoveringthe secret. For this example, let n=6, k=3.

3. Create the Polynomial

We need to create a polynomial of the form: y=f(x) mod p

i. Determine constant term and degree of polynomialf(x)=a ₀ +a ₁ x+a ₂ x ² +a ₃ x ³ + . . . +a _(k−1) x ^(k−1)

-   -   The constant term a₀=S    -   degree of polynomial=k−1    -   Hence for k=3 and S=1234, we need to build a polynomial with        degree 2 and a₀=1234        f(x)=1234+a ₁ x+a ₂ x ²        ii. Determine coefficients    -   Chose k−1 random numbers (use a Random (or pseudo random) Number        Generator) such that:        0<a _(n) <S    -   Let a₁=166; a₂=94    -   Hence, f(x)=1234+166x+94 x²        iii. Select a random prime number    -   Chose a random prime number (p) such that:        p>max(S,n)    -   Let p=1613        iv. Final polynomial        y=f(x)mod p        y=(1234+166x+94x ²)mod 1613        Creating the Shares

To divide the secret into n shares, we need to construct n points(shares) using the polynomial:y=(1234+166x+94x ²)mod 1613

Since n=6 for this example, we will have 6 points. Note that we startwith x=1 and NOT x=0.

For x=1 to 6, the 6 points are as follows:

(1, 1494); (2, 329); (3, 965); (4, 176); (5, 1188); (6, 775)

Out of these n (6) points, any k (3) points can be used to regeneratethe secret key.

Reconstructing the Secret from a Given Number of Shares

i. Get the secret integer

-   -   To reconstruct the secret, we need following information:        n=6, k=3, p=1613,    -   k shares:        (x0,y0)=(1,1494); (x1,y1)=(2,329); (x2,y2)=(3,965)    -   Once we have the above information, we can use a technique such        as Lagrange Interpolation which is known in the art and readily        appreciated by the skilled person. Using this technique we can        rebuild the entire polynomial. The coefficients can be        calculated according to formula below:        a _(i)(x)=[Σ^(k−1) _(i−0) y _(i)Π_(0←j←k−1,j≠i)(x−x _(j))/(x        _(i) −x _(j))] mod p    -   but since S=a₀, we only need to find a₀=a₀ (0)

$a_{0} = {\lbrack {\sum\limits_{i = 0}^{k - 1}{y_{i}{\prod\limits_{\underset{j \neq 1}{0 \leq j \leq {k - 1}}}\frac{- x_{j}}{x_{i} - x_{j}}}}} \rbrack{mod}\mspace{14mu} p}$where  x_(i) − x_(j) ≠ 0

The skilled person will understand that in the above, the exponent −1signifies taking the multiplicative inverse. Most programming languagescomprise inbuilt packages to perform mathematical operations such asmultiplicative inverse.

ii. Convert integer to desired format

-   -   If Step 1 was performed to convert a specific format to an        integer, we follow the reverse procedure to convert the integer        back to the desired format.        Secure Transmission of the Shares

As mentioned above, it is important that the shares of the secret aretransmitted to the respective recipients in a secure manner so as toprevent unauthorised parties from being able to reconstruct the secret.In a preferred embodiment, the secure transmission can be achieved asdescribed below.

A common secret (CS) can be established between two parties and thenused to generate a secure encryption key for transmission of one or moreof the shares. This common secret (CS) is not to be confused with thesecret (S) referred to above. The Common Secret (CS) is generated andused to enable secure exchange of the Secret (S) e.g. key or sharethereof.

The two parties could be any two of the wallet service provider, theuser, the safe storage resource or some other legitimate party.Hereafter, for the sake of convenience, they will be referred to as afirst node (C) a second node (S). The aim is to generate a common (CS)secret which both nodes know but without that common secret having beensent via a communication channel, thus eliminating the possibility ofits unauthorised discovery. The secret splitting plus safe storagetechnique, in combination with a secure transmission technique such asdescribed below, provides a secure key-management solution.

The secure transmission technique of the present invention involves theCS being generated at each end of the transmission in an independentmanner, so that while both nodes know the CS it has not had to travelover potentially unsecure communication channels. Once that CS has beenestablished at both ends, it can be used to generate a secure encryptionkey that both nodes can use for communication thereafter. This is ofparticular benefit during the wallet registration process, fortransmission of the split private key from one party to another.

FIG. 1 illustrates a system 1 that includes a first node 3 which is incommunication with a second node 7 over a communications network 5. Thefirst node 3 has an associated first processing device 23 and the secondnode 5 has an associated second processing device 27. The first andsecond nodes 3, 7 may include an electronic device, such as a computer,phone, tablet computer, mobile communication device, computer serveretc. In one example, the first node 3 may be a client (user) device andthe second node 7 may be a server. The server may be a digital walletprovider's server.

The first node 3 is associated with a first asymmetric cryptography pairhaving a first node master private key (V_(1C)) and a first node masterpublic key (P_(1C)). The second node (7) is associated with a secondasymmetric cryptography pair having a second node master private key(V_(1S)) and a second node master public key (P_(1S)). In other words,the first and second nodes are each in possession of respectivepublic-private key pairs.

The first and second asymmetric cryptography pairs for the respectivefirst and second nodes 3, 7 may be generated during a registrationprocess, such as registration for a wallet. The public key for each nodemay be shared publicly, such as over communications network 5.

To determine the common secret (CS) at both the first node 3 and secondnode 7, the nodes 3, 7 perform steps of respective methods 300, 400without communicating private keys over the communications network 5.

The method 300 performed by the first node 3 includes determining 330 afirst node second private key (V_(2C)) based on at least the first nodemaster private key (V_(1C)) and a Generator Value (GV). The GeneratorValue may be based on a message (M) that is a shared between the firstand second nodes, which may include sharing the message over thecommunications network 5 as described in further detail below. Themethod 300 also includes determining 370 a second node second public key(P_(2S)) based on at least the second node master public key (P_(1S))and the Generator Value (GV). The method 300 includes determining 380the common secret (CS) based on the first node second private key(V_(2C)) and the second node second public key (P_(2S)).

Importantly, the same common secret (CS) can also be determined at thesecond node 7 by method 400. The method 400 includes determining 430 afirst node second public key (P_(2C)) based on the first node masterpublic key (P_(1C)) and the Generator Value (GV). The method 400 furtherinclude determining 470 a second node second private key (V_(2S)) basedon the second node master private key (V_(1S)) and the Generator Value(GV). The method 400 includes determining 480 the common secret (CS)based on the second node second private key (V_(2S)) and the first nodesecond public key (P_(2C)).

The communications network 5 may include a local area network, a widearea network, cellular networks, radio communication network, theinternet, etc. These networks, where data may be transmitted viacommunications medium such as electrical wire, fibre optic, orwirelessly may be susceptible to eavesdropping, such as by aneavesdropper 11. The method 300, 400 may allow the first node 3 andsecond node 7 to both independently determine a common secret withouttransmitting the common secret over the communications network 5.

Thus one advantage is that the common secret (CS) may be determinedsecurely and independently by each node without having to transmit aprivate key over a potentially unsecure communications network 5. Inturn, the common secret may be used as a secret key (or as the basis ofa secret key) for encrypted communication between the first and secondnodes 3, 7 over the communications network 5.

The methods 300, 400 may include additional steps. The method 300 mayinclude, at the first node 3, generating a signed message (SM1) based onthe message (M) and the first node second private key (V_(2C)). Themethod 300 further includes sending 360 the first signed message (SM1),over the communications network, to the second node 7. In turn, thesecond node 7 may perform the steps of receiving 440 the first signedmessage (SM1). The method 400 also includes the step of validating 450the first signed message (SM2) with the first node second public key(P_(2C)) and authenticating 460 the first node 3 based on the result ofvalidating the first signed message (SM1). Advantageously, this allowsthe second node 7 to authenticate that the purported first node (wherethe first signed message was generated) is the first node 3. This isbased on the assumption that only the first node 3 has access to thefirst node master private key (V_(1C)) and therefore only the first node3 can determine the first node second private key (V_(2C)) forgenerating the first signed message (SM1). It is to be appreciated thatsimilarly, a second signed message (SM2) can be generated at the secondnode 7 and sent to the first node 3 such that the first node 3 canauthenticate the second node 7, such as in a peer-to-peer scenario.

Sharing the message (M) between the first and second nodes may beachieved in a variety of ways. In one example, the message may begenerated at the first node 3 which is then sent, over thecommunications network 5, the second node 7. Alternatively, the messagemay be generated at the second node 7 and then sent, over thecommunications network 5, to the second node 7. In yet another example,the message may be generated at a third node 9 and the message sent toboth the first and second nodes 3, 7. In yet another alternative, a usermay enter the message through a user interface 15 to be received by thefirst and second nodes 3, 7. In yet another example, the message (M) maybe retrieved from a data store 19 and sent to the first and second nodes3, 7. In some examples, the message (M) may be public and therefore maybe transmitted over an unsecure network 5.

In further examples, one or more messages (M) may be stored in a datastore 13, 17, 19, where the message may be associated with some entitysuch as digital wallet, or a communication session established betweenthe first node 3 and the second node 7. Thus the messages (M) may beretrieved and used to recreate, at the respective first and second nodes3, 7, the common secret (CS) associated with that wallet or session.

Advantageously, a record to allow recreation of the common secret (CS)may be kept without the record by itself having to be stored privatelyor transmitted securely. This may be advantageous if numeroustransactions are performed at the first and second nodes 3, 7 and itwould be impractical to store all the messages (M) at the nodesthemselves.

Method of Registration 100, 200

An example of a method of registration 100, 200 will be described withreference to FIG. 3 , where method 100 is performed by the first node 3and method 200 is performed by the second node 7. This includesestablishing the first and second asymmetric cryptography pairs for therespective first and second nodes 3, 7.

The asymmetric cryptography pairs include associated private and publickeys, such as those used in public-key encryption. In this example, theasymmetric cryptography pairs are generated using Elliptic CurveCryptography (ECC) and properties of elliptic curve operations.

Standards for ECC may include known standards such as those described bythe Standards for Efficient Cryptography Group (www.sceg.org). Ellipticcurve cryptography is also described in U.S. Pat. Nos. 5,600,725,5,761,305, 5,889,865, 5,896,455, 5,933,504, 6,122,736, 6,141,420,6,618,483, 6,704,870, 6,785,813, 6,078,667, 6,792,530.

In the method 100, 200, this includes the first and second nodesagreeing 110, 210 on a common ECC system and using a base point (G).(Note: the base point could be referred to as a Common Generator, butthe term ‘base point’ is used to avoid confusion with the GeneratorValue GV). In one example, the common ECC system may be based onsecp256K1 which is an ECC system used by Bitcoin. The base point (G) maybe selected, randomly generated, or assigned.

Turning now to the first node 3, the method 100 includes settling 110 onthe common ECC system and base point (G). This may include receiving thecommon ECC system and base point from the second node 7, or a third node9. Alternatively, a user interface 15 may be associated with the firstnode 3, whereby a user may selectively provide the common ECC systemand/or base point (G). In yet another alternative one or both of thecommon ECC system and/or base point (G) may be randomly selected by thefirst node 3. The first node 3 may send, over the communications network5, a notice indicative of using the common ECC system with a base point(G) to the second node 7. In turn, the second node 7 may settle 210 bysending a notice indicative of an acknowledgment to using the common ECCsystem and base point (G).

The method 100 also includes the first node 3 generating 120 a firstasymmetric cryptography pair that includes the first node master privatekey (V_(1C)) and the first node master public key (P_(1C)). Thisincludes generating the first master private key (V_(1C)) based, atleast in part, on a random integer in an allowable range specified inthe common ECC system. This also includes determining the first nodemaster public key (P_(1C)) based on elliptic curve point multiplicationof the first node master private key (P_(1C)) and the base point (G)according to the formula:P _(1C) =V _(1C) ×G  (Equation 1)

Thus the first asymmetric cryptography pair includes:

-   -   V_(1C): The first node master private key that is kept secret by        the first node.    -   P_(1C): The first node master public key that is made publicly        known.

The first node 3 may store the first node master private key (V_(1C))and the first node master public key (P_(1C)) in a first data store 13associated with the first node 3. For security, the first node masterprivate key (V_(1C)) may be stored in a secure portion of the first datastore 13 to ensure the key remains private.

The method 100 further includes sending 130 the first node master publickey (P_(1C)), over the communications network 5, to the second node 7.The second node 7 may, on receiving 220 the first node master public key(P_(1C)), store 230 the first node master public key (P_(1C)) in asecond data store 17 associated with the second node 7.

Similar to the first node 3, the method 200 of the second 7 includesgenerating 240 a second asymmetric cryptography pair that includes thesecond node master private key (V_(1S)) and the second node masterpublic key (P is). The second node master private key (V_(1S)) is also arandom integer within the allowable range. In turn, the second nodemaster public key (P_(1S)) is determined by the following formula:P _(1S) =V _(1S) ×G  (Equation 2)

Thus the second asymmetric cryptography pair includes:

-   -   V_(1S): The second node master private key that is kept secret        by the second node.    -   P_(1S): The second node master public key that is made publicly        known.

The second node 7 may store the second asymmetric cryptography pair inthe second data store 17. The method 200 further includes sending 250the second node master public key (P_(1S)) to the first node 3. In turn,the first node 3 may receive 140 and stores 150 the second node masterpublic key (P_(1S)).

It is to be appreciated that in some alternatives, the respective publicmaster keys may be received and stored at a third data store 19associated with the third node 9 (such as a trusted third party). Thismay include a third party that acts as a public directory, such as acertification authority. Thus in some examples, the first node masterpublic key (P_(1C)) may requested and received by the second node 7 onlywhen determining the common secret (CS) is required (and vice versa).

The registration steps may only need to occur once as an initial setupof, for example, the digital wallet.

Session Initiation and Determining the Common Secret by the First Node 3

An example of determining a common secret (CS) will now be describedwith reference to FIG. 4 . The common secret (CS) may be used for aparticular session, time, transaction, or other purpose between thefirst node 3 and the second node 7 and it may not be desirable, orsecure, to use the same common secret (CS). Thus the common secret (CS)may be changed between different sessions, time, transactions, etc.

The following is provided for illustration of the secure transmissiontechnique which has been described above.

Generating a Message (M) 310

In this example, the method 300 performed by the first node 3 includesgenerating 310 a message (M). The message (M) may be random, pseudorandom, or user defined. In one example, the message (M) is based onUnix time and a nonce (and arbitrary value). For example, the message(M) may be provided as:Message (M)=UnixTime+nonce  (Equation 3)

In some examples, the message (M) is arbitrary. However it is to beappreciated that the message (M) may have selective values (such as UnixTime, etc) that may be useful in some applications.

The method 300 includes sending 315 the message (M), over thecommunications network 3, to the second node 7. The message (M) may besent over an unsecure network as the message (M) does not includeinformation on the private keys.

Determining a Generator Value (GV) 320

The method 300 further includes the step of determining 320 a GeneratorValue (GV) based on the message (M). In this example, this includesdetermining a cryptographic hash of the message. An example of acryptographic hash algorithm includes SHA-256 to create a 256-bitGenerator Value (GV). That is:GV=SHA-256(M)  (Equation 4)

It is to be appreciated that other hash algorithms may be used. This mayinclude other has algorithms in the Secure Hash Algorithm (SHA) family.Some particular examples include instances in the SHA-3 subset,including SHA3-224, SHA3-256, SHA3-384, SHA3-512, SHAKE128, SHAKE256.Other hash algorithms may include those in the RACE Integrity PrimitivesEvaluation Message Digest (RIPEMD) family. A particular example mayinclude RIPEMD-160. Other hash functions may include families based onZémor-Tillich hash function and knapsack-based hash functions.

Determining a First Node Second Private Key 330

The method 300 then includes the step 330 of determining 330 the firstnode second private key (V_(2C)) based on the second node master privatekey (V_(1C)) and the Generator Value (GV). This can be based on a scalaraddition of the first node master private key (V_(1C)) and the GeneratorValue (GV) according to the following formula:V _(2C) =V _(1C)+GV  (Equation 5)

Thus the first node second private key (V_(2C)) is not a random valuebut is instead deterministically derived from the first node masterprivate key. The corresponding public key in the cryptographic pair,namely the first node second public key (P_(2C)), has the followingrelationship:P _(2C) =V _(2C) ×G  (Equation 6)

Substitution of V_(2C) from Equation 5 into Equation 6 provides:P _(2C)=(V _(1C)+GV)×G  (Equation 7)where the ‘+’ operator refers to elliptic curve point addition. Notingthat elliptic curve cryptography algebra is distributive, Equation 7 maybe expressed as:P _(2C) =V _(1C) ×G+GV×G  (Equation 8)

Finally, Equation 1 may be substituted into Equation 7 to provide:P _(2C) =P _(1C)+GV×G  (Equation 9.1)P _(2C) =P _(1C)+SHA-256(M)×G  (Equation 9.2)

Thus the corresponding first node second public key (P_(2C)) can bederivable given knowledge of the first node master public key (P_(1C))and the message (M). The second node 7 may have such knowledge toindependently determine the first node second public key (P_(2C)) aswill be discussed in further detail below with respect to the method400.

Generate a First Signed Message (SM1) Based on the Message and the FirstNode Second Private Key 350

The method 300 further includes generating 350 a first signed message(SM1) based on the message (M) and the determined first node secondprivate key (V_(2C)). Generating a signed message includes applying adigital signature algorithm to digitally sign the message (M). In oneexample, this includes applying the first node second private key(V_(2C)) to the message in an Elliptic Curve Digital Signature Algorithm(ECDSA) to obtain the first signed message (SM1).

Examples of ECDSA include those based on ECC systems with secp256k1,secp256r1, secp384r1, se3cp521r1.

The first signed message (SM1) can be verified with the correspondingfirst node second public key (P_(2C)) at the second node 7. Thisverification of the first signed message (SM1) may be used by the secondnode 7 to authenticate the first node 3, which will be discussed in themethod 400 below.

Determine a Second Node Second Public Key 370′

The first node 3 may then determine 370 a second node second public key(P_(2S)). As discussed above, the second node second public key (P_(2S))may be based at least on the second node master public key (P_(1S)) andthe Generator Value (GV). In this example, since the public key isdetermined 370′ as the private key with elliptic curve pointmultiplication with the base point (G), the second node second publickey (P_(2S)) can be expressed, in a fashion similar to Equation 6, as:P _(2S) =V _(2S) ×G  (Equation 10.1)P _(2S) =P _(1S)+GV×G  (Equation 10.2)

The mathematical proof for Equation 10.2 is the same as described abovefor deriving Equation 9.1 for the first node second public key (P_(2C)).It is to be appreciated that the first node 3 can determine 370 thesecond node second public key independently of the second node 7.

Determine the Common Secret 380 at the First Node 3

The first node 3 may then determine 380 the common secret (CS) based onthe determined first node second private key (V_(2C)) and the determinedsecond node second public key (P_(2S)). The common secret (CS) may bedetermined by the first node 3 by the following formula:S=V _(2C) ×P _(2S)  (Equation 11)Method 400 Performed at the Second Node 7

The corresponding method 400 performed at the second node 7 will now bedescribed. It is to be appreciated that some of these steps are similarto those discussed above that were performed by the first node 3.

The method 400 includes receiving 410 the message (M), over thecommunications network 5, from the first node 3. This may include themessage (M) sent by the first node 3 at step 315. The second node 7 thendetermines 420 a Generator Value (GV) based on the message (M). The stepof determining 420 the Generator Value (GV) by the second node 7 issimilar to the step 320 performed by the first node described above. Inthis example, the second node 7 performs this determining step 420independent of the first node 3.

The next step includes determining 430 a first node second public key(P_(2C)) based on the first node master public key (P_(1C)) and theGenerator Value (GV). In this example, since the public key isdetermined 430′ as the private key with elliptic curve pointmultiplication with the base point (G), the first node second public key(P_(2C)) can be expressed, in a fashion similar to Equation 9, as:P _(2C) =V _(2C) ×G  (Equation 12.1)P _(2C) =P _(1C)+GV×G  (Equation 12.2)

The mathematical proof for Equations 12.1 and 12.2 is the same as thosediscussed above for Equations 10.1 and 10.2.

The Second Node 7 Authenticating the First Node 3

The method 400 may include steps performed by the second node 7 toauthenticate that the alleged first node 3, is the first node 3. Asdiscussed previously, this includes receiving 440 the first signedmessage (SM1) from the first node 3. The second node 7 may then validate450 the signature on the first signed message (SM1) with the first nodesecond public key (P_(2C)) that was determined at step 430.

Verifying the digital signature may be done in accordance with anElliptic Curve Digital Signature Algorithm (ECDSA) as discussed above.Importantly, the first signed message (SM1) that was signed with thefirst node second private key (V_(2C)) should only be correctly verifiedwith the corresponding first node second public key (P_(2C)), sinceV_(2C) and P_(2C) form a cryptographic pair. Since these keys aredeterministic on the first node master private key (V_(1C)) and thefirst node master public key (P_(1C)) that were generated atregistration of the first node 3, verifying first signed message (SM1)can be used as a basis of authenticating that an alleged first nodesending the first signed message (SM1) is the same first node 3 duringregistration. Thus the second node 7 may further perform the step ofauthenticating (460) the first node 3 based on the result of validating(450) the first signed message.

The above authentication may be suitable for scenarios where one of thetwo nodes is a trusted node and only one of the nodes need to beauthenticated. For example, the first node 3 may be a client and thesecond node 7 may be a server trusted by the client such as a walletprovider. Thus the server (second node 7) may need to authenticate thecredentials of the client (first node 3) in order to allow the clientaccess to the server system. It may not be necessary for the server tobe authenticate the credentials of the server to the client. However insome scenarios, it may be desirable for both nodes to be authenticatedto each other, such as in a peer-to-peer scenario.

The Second Node 7 Determining the Common Secret

The method 400 may further include the second node 7 determining 470 asecond node second private key (V_(2S)) based on the second node masterprivate key (V is) and the Generator Value (GV). Similar to step 330performed by the first node 3, the second node second private key(V_(2S)) can be based on a scalar addition of the second node masterprivate key (V_(1S)) and the Generator Value (GV) according to thefollowing formulas:V _(2S) =V _(1S)+GV  (Equation 13.1)V _(2S) =V _(1S)+SHA-256(M)  (Equation 13.2)

The second node 7 may then, independent of the first node 3, determine480 the common secret (CS) based on the second node second private key(V_(2S)) and the first node second public key (P_(2C)) based on thefollowing formula:S=V _(2S) ×P _(2C)  (Equation 14)Proof of the Common Secret (CS) Determined by the First Node 3 andSecond Node 7

The common secret (CS) determined by the first node 3 is the same as thecommon secret (CS) determined at the second node 7. Mathematical proofthat Equation 11 and Equation 14 provide the same common secret (CS)will now be described.

Turning to the common secret (CS) determined by the first node 3,Equation 10.1 can be substituted into Equation 11 as follows:S=V _(2C) ×P _(2S)  (Equation 11)S=V _(2C)×(V _(2S) ×G)S=(V _(2C) ×V _(2S))×G  (Equation 15)

Turning to the common secret (CS) determined by the second node 7,Equation 12.1 can be substituted into Equation 14 as follows:S=V _(2S) ×P _(2C)  (Equation 14)S=V _(2S)×(V _(2C) ×G)S=(V _(2S) ×V _(2C))×G  (Equation 16)

Since ECC algebra is commutative, Equation 15 and Equation 16 areequivalent, since:S=(V _(2C) ×V _(2S))×G=(V _(2S) ×V _(2C))×G  (Equation 17)The Common Secret (CS) and Secret Key

The common secret (CS) may now be used as a secret key, or as the basisof a secret key in a symmetric-key algorithm for secure communicationbetween the first node 3 and second node 7. This communication may beused to convey part of a private key, a representation of or identifierfor a private key, or mnemonic for a private key. Therefore, once theinvention has been used during set-up of, for example, a digital walletor other controlled resource, secure communication between the partiescan be performed thereafter.

The common secret (CS) may be in the form of an elliptic curve point(xs, ys). This may be converted into a standard key format usingstandard publicly known operations agreed by the nodes 3, 7. Forexample, the xs value may be a 256-bit integer that could be used as akey for AES256 encryption. It could also be converted into a 160-bitinteger using RIPEMD160 for any applications requiring this length key.

The common secret (CS) may be determined as required. Importantly, thefirst node 3 does not need to store the common secret (CS) as this canbe re-determined based on the message (M). In some examples, themessage(s) (M) used may be stored in data store 13, 17, 19 (or otherdata store) without the same level of security as required for themaster private keys. In some examples, the message (M) may be publiclyavailable.

However depending on some application, the common secret (CS) could bestored in the first data store (X) associated with the first nodeprovided the common secret (CS) is kept as secure as the first nodemaster private key (V_(1C)).

It should be noted that the above-mentioned embodiments illustraterather than limit the invention, and that those skilled in the art willbe capable of designing many alternative embodiments without departingfrom the scope of the invention as defined by the appended claims. Inthe claims, any reference signs placed in parentheses shall not beconstrued as limiting the claims. The word “comprising” and “comprises”,and the like, does not exclude the presence of elements or steps otherthan those listed in any claim or the specification as a whole. In thepresent specification, “comprises” means “includes or consists of” and“comprising” means “including or consisting of”. The singular referenceof an element does not exclude the plural reference of such elements andvice-versa. The invention may be implemented by means of hardwarecomprising several distinct elements, and by means of a suitablyprogrammed computer. In a device claim enumerating several means,several of these means may be embodied by one and the same item ofhardware. The mere fact that certain measures are recited in mutuallydifferent dependent claims does not indicate that a combination of thesemeasures cannot be used to advantage.

What is claimed is:
 1. A computer-implemented method, comprising:determining a common secret at a first node in a network based, at leastin part, on a first node private key of the first node and a second nodepublic key of a second node in the network; using the common secret totransmit at least one share of a verification element that has beensplit into at least three shares to the second node to enable the secondnode to use the at least one share of the verification element tocompute the verification element, wherein the verification element isusable to control access to a digital wallet associated with a user; andstoring the at least three shares of the verification element atdifferent locations relative to each other, wherein a first share of theat least three shares is stored in or on a back-up or safe-storagefacility that is separate, independent, and/or distinct from thelocations in which other shares of the at least three shares are stored,and wherein the back-up or safe-storage facility is, or is operated by,a party that is independent of at least the first node and the user, andthat accepts responsibility for storing the share and supplying it uponrequest, and wherein a second share of the at least three shares isstored at a user device associated with the user and the digital wallet.2. The method of claim 1, wherein the verification element comprises: arepresentation of a cryptographic key different from the cryptographickey; or one or more elements that may be used to obtain thecryptographic key.
 3. The method of claim 1, wherein using the commonsecret to transmit the at least one share of the verification elementcomprises: using the common secret to generate an encryption key; andtransmitting the at least one share of the verification element in anencrypted format using the encryption key.
 4. The method of claim 1,wherein the verification element is a cryptographic key.
 5. The methodof claim 1, further comprising: splitting the verification element intothe plurality of shares such that the verification element can berestored or regenerated from two or more shares of the plurality ofshares, wherein no individual share of the plurality of shares issufficient to restore or regenerate the verification element.
 6. Themethod of claim 5, wherein Shamir's Secret Sharing Scheme is utilized aspart of splitting the verification element into the plurality of shares.